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DETAILED ACTION 

This Office action is in response to Applicant's amendment and request for 
reconsideration filed on 4/1 1/2005. Claims 1-4 and 9-35 are presented for further examination. 
Independent claims 1 and 17 have been amended. Claims 5-8 have been cancelled. Claims 20- 
35 have been added. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the first paragraph of 35 U.S.C 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

1. Claims 27 and 34 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply 
with the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. In particular, the specification failed to disclose using a snooping protocol to learn 
the contents of messages received by the router. 

The following is a quotation of the second paragraph of 35 U.S.C 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

2. Claims 27 and 34 are rejected under 35 U.S.C 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 
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3. With regard to claims 27 and 34, the term "snooping protocol" renders the claim indefinite. 
It is not clear what a "snooping protocol" is or how one would be used to the learn the contents 
of messages received by the router. It is presumed that the router snoops the messages in order 
to learn the contents of messages received by the router. 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

1. Claims 1-3 and 9-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over Martin 
et al. (U.S. Patent Number 6,765,927, hereinafter "Martin") and the Real-Time Streaming 
Protocol (RTSP) as set forth in Internet Engineering Task Force Request for Comment 2326 
(hereinafter RFC 2326). 

In considering claim 1, Martin discloses an intermediate network device for use within a 
computer network having a server configured to provide one or more data streams to a client, 
each stream having a corresponding bandwidth, the network device comprising: 

□ means for determining network traffic characteristics sufficient to identify a stream 
from the server to the client (Col 3, lines 21-24); 
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□ a packet classification engine for snooping on messages for determining the 
bandwidth of the stream (Col 3, lines 23-26 and Col 5, lines 1-5); [The bandwidth is 
be detected in order to properly generate the path message (Tspec). The RSVP 
component 246 in Figure 2 detects when a Path message should be sent based on an 
incoming packet and then further determines the network characteristics for 
generating an appropriate Path message. ] 

□ a resource reservation protocol (RSVP) transmitter proxy (Col 3, line 12) configured 
to reserve resources within the computer network on behalf of the server for 
allocation to the stream (Col 2, line 62 "flow characteristics" and Col 3, lines 23-27). 

Martin disclosed the invention substantially as claimed however, Martin failed to 
specifically recite what protocol the snooped messages of the stream (data flow) use. 
Nevertheless Martin specifically left his system open ended to work with any flow (Col 3, lines 
1 5-17). A well-known streaming protocol for data flow at the time of the invention was the 
Real-Time Streaming Protocol (RTSP), defined in RFC 2326. RFC 2326 disclosed a protocol 
(RTSP) for stream control (RFC 2326, Abstract). RFC 2326 further disclosed that stream 
delivery issues will rely on other protocols such as RSVP (RFC 2326, two paragraphs above 
Appendix A). Thus, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to design the Martin system to snoop RTSP stream messages, given that the RTSP 
protocol teaches using the stream delivery protocol RSVP in conjunction with RTSP, in order to 
provide both stream control and stream delivery. 
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In considering claim 2, Martin discloses the intermediate network device of claim 1 
wherein the RS VP transmitter proxy is configured to generate and send one or more RSVP Path 
messages on behalf of the server, the one or more RSVP Path messages containing the network 
traffic characteristics and the bandwidth of the stream (Col 3, lines 23-27). 

In considering claim 3, Martin discloses the intermediate network device of claim 2 
wherein the RSVP transmitter proxy is configured to terminate RSVP Reservation (Resv) 
messages that are sent to the Server (Col 3, lines 42-46). [Figure 1 also shows a clear illustration 
of where the Resv messages travel, from the client (Component 120) to termination at the proxy 
server (Component 140).] 

In considering claim 9, the intermediate network device of claim 8 wherein the packet 
classification engine is configured to extract the bandwidth of the stream from one or more 
messages whose contents are organized at least in part in accordance with the Session 
Description Protocol (SDP). It was widely known that the Session Description Protocol (SDP) 
can be used to describe characteristics of RTSP streams (including bandwidth) as evidenced in 
the RTSP protocol (RFC 2326, Appendix C) thus, it would have been obvious to extract any 
relevant stream information in accordance with the SDP protocol. 

In considering claim 10, Martin discloses the intermediate network device of claim 9 
further comprising a session manager configured to store the network traffic characteristics and 
bandwidth of the stream (Col 4, lines 27-29). 

In considering claim 1 1, the RTSP protocol discloses an RTSP state manager which 
includes one or more state machine engines, configured to maintain the RTSP state of the stream 
(RFC 2326, Appendix A.2). 
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In considering claim 12, Martin discloses the intermediate network device of claim 2 
wherein 

a the client has a network layer address and a transport layer port for use in receiving 
the stream from the server (Col 4, line 59-61; included in a Path message), 

□ the server has a network layer address and a transport layer port for use in sending the 
stream to the client (Col 4, line 59-61), and 

□ the network traffic characteristics include the client's network layer address and 
transport layer port and the server's network layer address and transport layer port 
(Col 4, line 59-61). 

In considering claim 13, Martin discloses the intermediate network device of claim 12 
wherein the stream uses a given transport layer protocol, and the network traffic characteristics 
include the given transport layer protocol (Col 4, line 59-61). 

In considering claim 14, Martin discloses the intermediate network device of claim 13 
wherein the RSVP Path messages generated and sent by the RSVP transmitter proxy on behalf of 
the server include a session object containing the client's network layer address and transport 
layer port and the transport layer protocol associated with the stream (Col 4, line 59-61). 

In considering claim 15, Martin discloses the intermediate network device of claim 14 
wherein the RSVP Path message includes a sender template object containing the server's 
network layer address and transport layer port associated with the stream (Col 4, line 59-61). 

In considering claim 16, Martin discloses the intermediate network device of claim 15 
wherein the RSVP Path message includes a sender Tspec object containing the bandwidth of the 
stream (Col 5, line 4). 
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2. Claim 4 is rejected under 35 U.S.C. 103(a) as being unpatentable over Martin as applied to 
claims 1-3 above, and further in view of the Resource ReSerVation Protocol (RSVP) as set forth 
in Internet Engineering Task Force Request for Comment 2205 (hereinafter RFC 2205). 

In considering claim 4, Martin discloses an RSVP host proxy which is capable of 
generating RSVP Path messages and receiving RSVP Resv messages on behalf of a server as 
stated above. However, Martin fails to disclose an RSVP host proxy which is capable of 
generating RSVP Path Teardown messages on behalf of a server. Nonetheless, the use of RSVP 
Path Teardown messages is well known, as referenced by RFC 2205. 

Martin discloses that the RSVP host proxy supports the RSVP protocol set forth in RFC 
2205 (Martin Col 3, lines 1-5). Section 2.4 of RFC 2205 discusses the use of RSVP Path 
Teardown messages within the RSVP protocol. RFC 2205 goes on to recommend "that all end 
hosts send a teardown request as soon as an application finishes" (Section 2.4, paragraph 1). 
Thus, giving the teachings of RFC 2205, it would have been obvious to a person having ordinary 
skill in the art to design the Martin system to support RSVP Path Teardown messages, since the 
messages are recommended by the RSVP protocol. 

3. Claims 17-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over Martin and 
"Format of the RSVP DCLASS Object" Request for Comment 2996 (hereinafter RFC 2996). 

In considering claim 17, claim 17 is rejected using similar rationale as set forth with 
regard to claim 1 and the Martin reference. 
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In further considering claims 17-19 and the use of DSCP, as discussed above Martin 
disclosed a means for obtaining the stream bandwidth and a means for including the obtained 
bandwidth within an RSVP Path message Tspec object. However, Martin fails to disclose a 
means for obtaining a differentiated services codepoint (DSCP) value that is based on the 
bandwidth of the stream. Martin also fails to disclose the intermediate network device of claim 
17 wherein the RSVP transmitter proxy is configured to load the DSCP into the RSVP Path 
message generated and sent on behalf of the server. Martin further fails to disclose the 
intermediate network device of claim 18 wherein the RSVP Path message includes a DCLASS 
object containing the DSCP. 

Nonetheless, the use of RSVP Path messages that contain differentiated services 
codepoint (DSCP) values within DCLASS objects was well known as evidenced by RFC 2996 
(Abstract). In an analogous art, RFC 2996 disclosed the use of DCLASS objects within RSVP 
messages in order to enhance the manageability of application traffic QoS in a differentiated 
service network (RFC 2996 Abstract). Thus, it would have been obvious to one of ordinary skill 
in the art to design the Martin system to obtain a differentiated services codepoint (DSCP) value 
that is based on the bandwidth of the stream, in order "to enhance the manageability of 
application traffic QoS in a differentiated service network" (RFC 2996, Abstract). Further, it 
would have also been obvious to include within an RSVP path message, the determined DSCP 
value in a DCLASS object, given that such usage is disclosed in the RFC 2996 protocol and 
would enhance the manageability of application traffic QoS in a differentiated service network 
(RFC 2996, Abstract). 
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4. Claims 20-25, 27, 29-32, and 34 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Martin and Merwe et al. (mmdump: A tool for Monitoring Internet Multimedia Traffic; 
hereinafter Merwe). 

In considering claims 20-21, 22-24, and 29-3 1, Martin disclosed a method for providing 
one or more data streams from a server to a client, each stream having a corresponding 
bandwidth, the method comprising: 

□ determining network traffic characteristics sufficient to identify a stream from the 
server to the client (determining the flow meets RS VP sender host proxy criteria) 
(Col 3, lines 21-22); 

□ determining the bandwidth of the stream (Col 3, lines 21-26 and Col 5, lines 1-10) 
[The bandwidth must be detected in order to properly generate the path message 
(Tspec). The RS VP component 246 in Figure 2 detects when a Path message 
should be sent based on an incoming packet and then further determines the 
network characteristics for generating an appropriate Path message.] 

□ sending via a resource reservation protocol (RS VP) transmitter proxy, messages 
to nodes along a data path from the server to the client to reserve resources within 
the computer network on behalf of the server for allocation of the stream (Col 3, 
lines 26-33) 

□ receiving a RSVP reply message from the client, the RSVP rely message 
reserving resources for the requested traffic flow (Resv message) (Col 3, lines 33- 
46) 
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□ receiving a data message of the traffic flow from the server and transmitting the 
data message of the traffic flow with a resource reservation indicia in the data 
message, the resource reservation indicia to direct the data message to travel 
along the reserved resources (Col 4, lines 27-38). 



Martin disclosed the invention substantially as claimed however Martin failed to 
specifically recite receiving a message from a client to a server, wherein the client message 
requesting that the server begin sending a traffic flow to the client. Further Martin failed to 
specifically recite receiving a response message from the server, the response message 
responding to the message from the client. Nevertheless Martin disclosed the detection of a flow 
from a server to a client (Col 3, lines 15-20). Further it was also well known in the art at the time 
of the invention to detect the start of a flow based on a client request and server response, as 
evidenced by Merwe. In an analogous art, Merwe disclosed a system for monitoring multimedia 
traffic flows using the RTSP protocol (abstract). The Real Time Streaming Protocol (RTSP) is 
the dominant control protocol for controlling the streaming of content on the Internet (Sect. 2.2). 
Merwe' s system detects client requests for the server to begin sending a traffic flow (RTSP 
describe message) and the corresponding server response (media specific information about the 
stream) (Section 2.2 and Figure 1). It would have been obvious. to one of ordinary skill in the art 
at the time of the invention to modify Martin's system to detect traffic flows based on the client 
request and server response pair of RTSP as disclosed by Merwe (Section 2.2), since the RTSP 
protocol is the dominant control protocol for streaming content on the Internet (Merwe Sect 2.2. 

1 st n). 
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In considering claims 25, 27, 32, and 34, Martin disclosed means for reading (snooping) 
messages received by the router parameters of a traffic flow, the traffic flow requested by the 
client for the server to transmit to the client (determining that the data packet meets RSVP sender 
host proxy criteria) (Col 3, lines 21-22). 

5. Claims 28 and 35 are rejected under 35 U.S.C. 103(a) as being unpatentable over Martin and 
Merwe et al. (mmdump: A tool for Monitoring Internet Multimedia Traffic; hereinafter Merwe) 
as applied above and further in view of Gai et al. (RSVP Proxy - Internet Draft; hereinafter Gai). 

In considering claims 28 and 35, as discussed above Merwe disclosed receiving first 
message by the router, the first messages originating from computers connected to the Internet 
and directed to the server (Sect. 2.2. DESCRIBE message) and receiving second messages by the 
router, the second messages originating from the server and directed to client connected to the 
internet (Sect. 2.2. server response - media specific information). However both Martin and 
Merwe failed to specifically recite connecting the router one hop away from the server. In an 
analogous art, Gai disclosed an RSVP Sender Proxy (see Section 3) analogous to Martin's proxy. 
Gai disclosed the router (RSVP proxy) is one hop away from the server (Figure 1) such that the 
most Path message enabled additional downstream network elements can benefit from the 
information carried in the signaling messages (Section 4, Where to Proxy). It would have been 
obvious to one of ordinary skill in the art at time of the invention to incorporate the teachings of 
Gai within the combined Martin and Merwe system so that the most Path message enabled 
downstream network elements can benefit from the information carried in the signaling messages 
(Gai Section 4, Where to Proxy). 
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Allowable Subject Matter 
Claims 26 and 33 are objected to as being dependent upon a rejected base claim, but 
would be allowable if rewritten in independent form including all of the limitations of the base 
claim and any intervening claims. 

Response to Arguments 
4. In response to Applicant's request for reconsideration filed on 4/1 1/05, the following factual 
arguments are noted: 

a. Martin failed to disclose an equivalent to "snooping." 

b. The Examiner failed to point where Martin suggested the combination of Martin and 
RFC 2996. 

c. Martin fails to disclose receiving a message from the client from which information is 
derived. 

In considering (a), Examiner respectfully disagrees with Applicant's argument. Martin 
clearly disclosed the equivalent of snooping. For instance switch 140 (figure 1) intercepts data 
packets regularly to determine intercepted packets meet RS VP sender host proxy criteria thereby 
requiring and RSVP Path message to be transmitted (Col 3, lines 21-26). 



In considering (b), Examiner respectfully disagrees with Applicant's argument. In 
response to applicant's argument that there is no suggestion to combine the references, the 
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examiner recognizes that obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there is some teaching, 
suggestion, or motivation to do so found either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). 
In the instant case, the rationale for the combination of Martin and RFC 2296 is clearly mapped 
above and specifically drawn from RFC 2296. 

In considering (c), Applicant arguments are noted however they are moot in view of the 
new grounds of rejection set forth. 

Conclusion 

5. The prior art made of record, in PTO-892 form, and not relied upon is considered pertinent 
to applicant's disclosure. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
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will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1. 136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sean Reilly whose telephone number is 571-272-4228. The 
examiner can normally be reached on M-F 8-5. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glen Burgess can be reached on 571-272-3949. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 




MARC D. THOMPSON 




PRIMARY EXAMINER 



